1. Field of the Invention
The invention relates to suspending accesses by IMS batch application programs to shared IMS resources. The invention also relates to IMS batch application programs maintaining control of independently obtained resources while the IMS system temporarily obtains exclusive control of the shared IMS resources.
2. Description of the Related Art
IBM's Information Management System (“IMS”) is a widely used database management system. IMS “implemented the hierarchical model tree structure to organize the collection of records in a one-to-many entity-relationship data model.” K. R. Blackman, IMS Celebrates Thirty Years as an IBM Product, IBM Systems Journal, Vol. 37, No. 4, 596 (1998). Today, a large percentage of the top worldwide companies in the areas of manufacturing, finance, banking, retailing, aerospace, communications, government, insurance, high technology, and health care use IMS to run their day-to-day database operations. Id. at 597.
“The IMS database (DB) function provides a full-function resource manager and a fast path resource manager for hierarchical database management . . . . The data managed by IMS are organized in hierarchical database records. A database record is composed of segments, a segment being the smallest piece of information that IMS can store. A segment contains fields that are the smallest pieces of data an application program can manipulate. A field is identified as a unique key field that can be used to navigate the database to find a specific segment. The hierarchical structure of the segments establishes the structure of the database record. A root segment identifies a database record, and a database record cannot exist without a root segment. Dependent segments are the pieces of data that complete the rest of a database record. The IMS DB full-function resource manager provides sequential access, indexed sequential access, and direct access for database processing. The fast path DB resource manager provides the direct method for processing data by using direct access pointers to the segments.” Id. at 597-98. An OS dataset is a physical device on which an IMS database is stored.
“The fundamental architecture of IMS consists of a control region, a DLI secondary address space (DLISAS), a DBRC address space, an IRLM address space, and one or more dependent regions [hereinafter “IMS Database Management System” or “IMS system”]. The control region is the execution environment for the IMS system software, the control blocks, and storage pools required for managing communication access and application program scheduling. The control region also contains the fast path system software for managing access to fast path databases. This isolates the IMS system functions from the customer's application programs to maintain the integrity of the IMS system. The DLISAS execution environment contains the IMS DB full-function system software, control blocks, and storage pools for managing access to the full-function databases. The dependent regions provide the execution environments for the application programs to process transactions.” Id. at 599.
Periodically, IMS databases need to be taken offline for maintenance. For example, because IMS databases become physically disorganized as the database is utilized and modified, they periodically need to be reorganized. The degree of disorganization is usually a function of the number of segments added, deleted, or updated. Segments being added or split as the result of an update tend to be physically located in a block other than their root segment or hierarchical predecessor. Subsequent retrieval of these new or split segments require additional DASD read requests, thus degrading the performance of the database. If a database is not reorganized, its performance degrades, at least in part because more I/O operations are required to retrieve data. Unloading and reloading a complete database is a common technique used to reorganize a database. This technique requires that the entire database be offline and unavailable during the period of time that that database is being reorganized. When a database is reorganized, its primary and secondary indexes have to be updated as well.
Dependent regions are divided into short running thread and long running thread dependent regions. If only short running thread dependent regions are accessing the shared IMS resources (e.g., an IMS database) and IMS needs to access the shared IMS shared resources (e.g., to perform maintenance of a database), IMS will allow such access. However, processing by any and all IMS Batch Message Processing (BMP) regions, or Data Language 1 (DL1) regions including DBB regions (hereinafter “IMS batch regions”), which are long running thread dependent regions, must be terminated or abended to release control of the shared IMS resources to the IMS system.
By terminating processing of the IMS batch regions, business application programs become unavailable. This is perceived as an undesirable outage or period of downtime to users of the business application. Furthermore, if application programs are terminated or abended prematurely, this prevents application continuity. For example, an application may be terminated in the middle of printing a report, and a complete report may have to be printed in pieces. Furthermore, when application programs are terminated, resources need to be expended to restart such applications. In addition, there is greater risk of operational impact when applications are restarted, such as operator error. Also, to be able to restart an application program, it must implement, or be modified to implement, functional restart and repositioning programming.
On the other hand, if IMS batch regions are not terminated, and business applications are allowed to continue running, maintenance of the IMS resources (e.g., IMS database) cannot occur and less than optimum performance may result.
Thus, this has caused a dilemma in the prior art between the desirability of application program availability versus IMS resource maintenance.
BMC Software's Application Restart Control (“ARC”) product allows IMS resources being utilized by an application program to be released without terminating the job step. However, the ARC product abends the application program and then must restart it for it to resume operations. Thus, the application program must include, or be modified to include, restart programming. Furthermore, the ARC product supports only BMP IMS application programs and not DL1 or DBB IMS application programs.
It should also be noted that IMS batch jobs can be running while the IMS system is offline. Nonetheless, even if these IMS batch jobs have exclusive access to IMS resources while the IMS system is offline, they may preclude tasks such as batch database reorganizations, and DASD management functions, such as volume defrag, database dataset moves from one DASD volume to another, and Disaster Recovery backups, and other general DASD management issues. These tasks and general DASD management issues are performed by a system hereinafter referred to as a “non-IMS system agent.” Thus, there also is a need for such IMS batch jobs to temporarily suspend their access to IMS resources shared with such a non-IMS system agent.
Therefore, a need exists for the capability of suspending accesses by BMP, DL1, or DBB IMS application programs to shared IMS resources without terminating or abending the programs. A further need exists for enabling BMP, DL1, and DBB IMS application programs to resume their accesses to shared IMS resources, after suspension, without requiring the application programs to be restarted or for them to contain restart programming. Still another need exists for an external interface to such application program suspend and resume capability.